Frontend System Design Trade-offs: A Comprehensive Guide

Introduction
Rendering Strategies
State Management
Data Fetching
Performance Optimization
Component Architecture
Styling Approaches
Routing Architecture
Micro-Frontend Architecture
Security Considerations
Accessibility
Observability
Testing Strategy
Deployment Strategies
Mobile Considerations
Interview Framework

Introduction

This guide provides a comprehensive overview of frontend system design trade-offs for technical interviews at companies like Google, Amazon, Microsoft, and other tech giants. Each section explores real-world decisions, their implications, and when to apply them.

Key Principle: Every architectural decision is a trade-off. There are no universally "best" solutions—only appropriate choices for specific contexts.

Rendering Strategies

CSR vs SSR vs SSG vs ISR

Approach	Pros	Cons	Best Use Cases	Example
CSR (Client-Side Rendering)	• Simple deployment • Low server costs • Rich interactivity • Easy state management	• Slow First Contentful Paint • Poor SEO (without workarounds) • Blank screen on slow networks • Higher client device load	• Admin dashboards • Internal tools • Apps behind auth • Highly interactive SPAs	Gmail, Notion
SSR (Server-Side Rendering)	• Fast First Contentful Paint • Excellent SEO • Works without JS • Fresh data on every request	• Higher server costs • TTFB dependency • More complex deployment • Hydration overhead	• E-commerce product pages • News sites • Social media feeds • Content-heavy apps	Amazon, Twitter
SSG (Static Site Generation)	• Fastest possible loads • CDN-friendly • Lowest hosting cost • Best SEO	• Build time scales poorly • Data can be stale • Not suitable for personalized content	• Blogs • Documentation • Marketing sites • Landing pages	Vercel docs, Gatsby sites
ISR (Incremental Static Regeneration)	• Balance of fresh + fast • On-demand regeneration • CDN benefits • Scales better than SSG	• More complex mental model • Stale-while-revalidate behavior • Platform-specific (Next.js)	• Product catalogs • SEO landing pages • News sites with updates	E-commerce listings

Decision Framework:

Is data user-specific?
  ├─ Yes → CSR or SSR
  │   └─ Need SEO?
  │       ├─ Yes → SSR
  │       └─ No → CSR
  └─ No → SSG or ISR
      └─ Updates frequently?
          ├─ Yes → ISR
          └─ No → SSG

Hydration Strategies

Strategy	Description	Trade-off	Use When
Full Hydration	Hydrate entire page at once	Simple but slow on large pages	Small to medium apps
Progressive Hydration	Hydrate components as needed	Complex but faster TTI	Large apps with clear priority
Partial Hydration (Islands Architecture)	Only hydrate interactive parts	Best performance but requires careful planning	Mixed static/dynamic content
Resumability (Qwik)	Zero hydration, resume from HTML	Fastest but new paradigm	Performance-critical apps

Key Insight: Hydration is pure overhead. The less you hydrate, the faster your app, but the more complex your architecture.

Streaming SSR

Pros:

Progressive rendering (faster perceived performance)
Doesn't block on slow data fetching
Better TTFB for complex pages

Cons:

More complex error handling
Requires React 18+ or similar framework support
Can't set HTTP headers after streaming starts

Use when: You have pages with mixed fast/slow data sources (e.g., user profile with slow recommendation feed).

State Management

Local vs Global State

Approach	Pros	Cons	Best For
Local State (useState, useReducer)	• Simple mental model • No external dependencies • Predictable performance • Easy to test	• Hard to share between distant components • Prop drilling • Duplication across components	• UI state (modals, forms) • Component-specific logic • Temporary data
Context API	• Built into React • No extra library • Good for theme/i18n	• Re-renders all consumers • Poor performance at scale • Not designed for frequent updates	• Global config • Theme/locale • User authentication status
Redux	• Predictable state changes • Time-travel debugging • Middleware ecosystem • DevTools	• Boilerplate heavy • Learning curve • Over-engineering for simple apps	• Complex business logic • Apps with many features • Need for undo/redo
Zustand	• Minimal boilerplate • Great DX • Flexible	• Less mature ecosystem • Fewer DevTools	• Medium apps • When Redux feels heavy
Jotai/Recoil	• Atomic state • Minimal re-renders • Derived state	• Different paradigm • Smaller community	• Performance-critical apps • Complex derived state

Server State Management

Library	Pros	Cons	Use When
React Query / TanStack Query	• Caching built-in • Automatic refetching • Optimistic updates • DevTools	• Learning curve • Additional dependency	Default choice for server state
SWR	• Simpler API • Stale-while-revalidate • Smaller bundle	• Fewer features than React Query	Simpler apps, Vercel ecosystem
Apollo Client (GraphQL)	• GraphQL integration • Normalized cache • Real-time subscriptions	• Heavy bundle • GraphQL-only • Complex cache	GraphQL apps with complex data
RTK Query	• Redux integration • Code generation • Cache invalidation	• Redux required • More setup	Already using Redux

Golden Rule:

UI state → Local state
Server state → React Query/SWR
Cross-feature business logic → Redux/Zustand

State Synchronization

Pattern	Description	Trade-off
Optimistic Updates	Update UI before server confirms	Fast UX but requires rollback logic
Pessimistic Updates	Wait for server before updating UI	Slower UX but simpler logic
Event Sourcing	Store state changes as events	Complete history but complex
CQRS	Separate read/write models	Scales well but more infrastructure

Data Fetching

API Architectural Patterns

Pattern	Pros	Cons	Best For
REST	• Simple, well-understood • HTTP caching friendly • Stateless • Wide tooling support	• Over-fetching (get more data than needed) • Under-fetching (multiple requests needed) • Versioning challenges	• Public APIs • Simple CRUD operations • When HTTP caching is critical
GraphQL	• Request exactly what you need • Single endpoint • Strong typing • Real-time subscriptions	• Complex caching • Learning curve • Heavier client bundle • Potential N+1 queries	• Complex, nested data • Mobile apps (reduce requests) • Rapidly changing requirements
tRPC	• End-to-end type safety • No code generation • Simple setup	• Backend lock-in (TypeScript/Node) • Smaller ecosystem • Not suitable for public APIs	• Full-stack TypeScript apps • Internal tools • Monorepos
gRPC	• Extremely fast (binary) • Built-in streaming • Strong contracts	• Browser support requires proxy • Debugging harder • Overkill for simple apps	• Microservices • High-performance needs • Server-to-server

Interview Insight: REST's advantage is HTTP caching infrastructure. GraphQL trades that for precision but requires custom caching solutions.

Caching Strategies

Layer	Strategy	Pros	Cons
Browser Cache	HTTP headers (Cache-Control, ETag)	• Free • Automatic • Reduces server load	• Hard to invalidate • User-specific data risks • Storage limits
CDN Cache	Edge caching (Cloudflare, Fastly)	• Massive scale • Geographic distribution • DDoS protection	• Stale data • Purge delays • Cost at scale
In-Memory Cache	React Query, SWR, Redux cache	• Instant access • Full control	• Memory leaks if not managed • Lost on refresh
Service Worker	Progressive Web App cache	• Offline support • Full control • Background sync	• Complexity • Debugging harder • Version management
IndexedDB	Client-side database	• Large storage • Structured queries	• Async API complexity • Browser differences

Cache Invalidation Strategies:

Time-based (TTL)
Event-based (on mutation)
Stale-while-revalidate
Cache-aside pattern

Real-time Data

Technology	Pros	Cons	Use When
WebSocket	• True bidirectional • Low latency • Persistent connection	• More complex infrastructure • Scaling challenges • Connection management	• Chat apps • Live dashboards • Multiplayer games
Server-Sent Events (SSE)	• Simpler than WebSocket • Auto-reconnect • HTTP/2 friendly	• One-way only • Limited browser support	• Live feeds • Notifications • Stock tickers
Long Polling	• Works everywhere • Simple	• Inefficient • Higher latency	• Legacy browser support • Fallback option
GraphQL Subscriptions	• Integrated with queries • Type-safe	• Requires GraphQL • WebSocket dependency	• GraphQL apps needing real-time

Performance Optimization

Bundle Optimization

Technique	Impact	Trade-off	Implementation
Code Splitting	Reduce initial bundle by 40-70%	More network requests, complexity	Dynamic imports, route-based splitting
Tree Shaking	Remove unused code (10-30% reduction)	Requires ES modules, build tool config	ESM exports, sideEffects: false
Minification	30-50% size reduction	Build time increase	Terser, esbuild
Compression (Gzip/Brotli)	60-80% size reduction	Server CPU usage	Nginx/CDN configuration
Dynamic Imports	Load code on demand	Waterfalls if not careful	React.lazy(), Next.js dynamic()
Bundle Analysis	Identify large dependencies	Time investment	webpack-bundle-analyzer

Bundle Budget Recommendations:

Initial JS: < 200KB (gzipped)
Total page weight: < 1MB
Time to Interactive: < 3.5s (3G)

Runtime Performance

Optimization	Benefit	Cost	When to Apply
Memoization (useMemo, memo)	Prevent expensive recalculations	Memory overhead, mental complexity	Expensive computations only
useCallback	Prevent prop changes	Negligible	Passing callbacks to memoized components
Virtualization (react-window)	Render only visible items	Implementation complexity	Lists with 100+ items
Debouncing/Throttling	Reduce function calls	Delayed response	Search inputs, scroll handlers
Web Workers	Offload heavy computation	Communication overhead	Image processing, data parsing
Concurrent Features (React 18)	Non-blocking rendering	Requires React 18+	Complex UIs with heavy updates

Performance Anti-patterns:

Premature optimization (optimize what matters)
Over-memoization (everything wrapped in useMemo)
Inline object/array creation in render
Anonymous functions in JSX (when causing issues)

Network Performance

Strategy	Impact	Implementation
Resource Hints (prefetch, preload, dns-prefetch)	Reduce perceived latency	`<link rel="prefetch">`
HTTP/2 & HTTP/3	Multiplexing, reduced latency	Server/CDN configuration
Image Optimization (WebP, AVIF, lazy loading)	50-80% size reduction	Picture element, loading="lazy"
Request Batching	Reduce waterfall	GraphQL, custom batch endpoint
Service Worker Caching	Offline support, instant loads	SW registration, cache strategies

Rendering Performance

Critical Rendering Path Optimization:

Metric	Target	Strategy
FCP (First Contentful Paint)	< 1.8s	Inline critical CSS, reduce blocking resources
LCP (Largest Contentful Paint)	< 2.5s	Optimize images, preload key resources
TTI (Time to Interactive)	< 3.8s	Code splitting, reduce JavaScript
CLS (Cumulative Layout Shift)	< 0.1	Reserve space, avoid dynamic content
FID (First Input Delay)	< 100ms	Reduce long tasks, use web workers
INP (Interaction to Next Paint)	< 200ms	Optimize event handlers, debounce

Component Architecture

Component Patterns

Pattern	Description	Pros	Cons	Use Case
Presentational Components	Pure UI, no business logic	Reusable, testable	More files	UI libraries, design systems
Container Components	Handle data/logic, pass to presentational	Separation of concerns	Boilerplate	Feature components
Compound Components	Multiple components work together	Flexible API, control inversion	More complex	Tabs, Accordion, Select
Render Props	Share code via function prop	Flexible, composable	Callback hell risk	Auth, data fetching
Higher-Order Components	Enhance components with shared logic	Reusable logic	Props collision, wrapper hell	Legacy code, cross-cutting
Hooks	Share stateful logic	Composable, clean	Rules of Hooks	Modern React standard
Controlled vs Uncontrolled	Parent controls state vs local state	Controlled: full control; Uncontrolled: simpler	Controlled: more code	Forms (controlled), simple inputs (uncontrolled)

Composition vs Inheritance

Composition (React's recommendation):

// Good: Composition
<Layout>
  <Sidebar />
  <Content />
</Layout>

Why composition over inheritance:

More flexible
Easier to understand
Avoids tight coupling
Better tree shaking

Code Reusability

Level	Strategy	When to Extract
Functions	Utility functions	Used 3+ times
Hooks	Custom hooks	Shared stateful logic
Components	Reusable UI	Used 2+ times, stable API
Libraries	Published packages	Used across projects

YAGNI Principle: Don't extract until you need it in multiple places.

Styling Approaches

CSS Methodologies

Approach	Pros	Cons	Bundle Impact	Best For
Plain CSS	• Fast • Simple • No build step	• Global scope • Naming conflicts • Hard to delete	Smallest	Small projects
CSS Modules	• Scoped by default • Type-safe (with TS) • No runtime	• Tooling required • Dynamic styles harder	Small	Component libraries
Styled-components / Emotion	• Dynamic styling • Theming • Co-location	• Runtime cost • Larger bundle • SSR complexity	Medium-Large	Apps with complex theming
Tailwind CSS	• Fast development • Consistent design • Purge removes unused	• Large class names • HTML clutter • Learning curve	Small (with purge)	Rapid prototyping, design systems
CSS-in-JS (Zero-runtime) (Vanilla Extract, Linaria)	• Type-safe • No runtime cost • Scoped	• More setup • Less flexible	Small	Performance-critical apps
Sass/Less	• Variables, mixins • Mature ecosystem	• Extra build step • Can encourage complexity	Small	Traditional projects

Runtime vs Build-time

Runtime CSS-in-JS (Styled-components, Emotion):

Pros: Maximum flexibility, dynamic theming
Cons: ~10-30KB runtime cost, serialization overhead
Use when: Heavy theming, runtime style changes

Build-time CSS (Tailwind, CSS Modules, Vanilla Extract):

Pros: Zero runtime, smaller bundles
Cons: Less dynamic, more build config
Use when: Performance is critical

Theming Systems

Approach	Flexibility	Performance
CSS Variables	High	Best
Context + CSS-in-JS	Very High	Moderate
Class swapping	Low	Best
Theme prop injection	High	Poor (re-renders)

Routing Architecture

Client vs Server Routing

Type	Pros	Cons	Best For
Client Routing (React Router, Tanstack Router)	• Instant transitions • Preserved state • Smooth animations • No full page reload	• Initial SEO challenges • Deep linking requires setup • Larger initial bundle	• SPAs • Apps behind auth • Interactive dashboards
Server Routing (Traditional MPAs)	• SEO friendly • Simple mental model • Progressive enhancement • Smaller JS bundles	• Slower navigation • Lost state on navigation • No smooth transitions	• Content sites • Marketing pages • E-commerce
Hybrid (Next.js App Router, Remix)	• Best of both worlds • Fast navigation + SEO • Streaming	• Framework-specific • More complexity	• Modern web apps (default choice)

Route-based Code Splitting

Automatic in Next.js/Remix, manual in React Router:

// Lazy load routes
const Dashboard = lazy(() => import('./Dashboard'));

Benefits:

Smaller initial bundles
Faster first load
Load code as needed

Trade-offs:

Route transition delay (can be mitigated with prefetch)
More complex error handling

Deep Linking

Challenges:

Preserving app state in URLs
Handling authentication redirects
Shareable links

Solutions:

Query parameters for filters
Route parameters for resources
Hash fragments for scroll position

Micro-Frontend Architecture

Integration Approaches

Approach	Pros	Cons	Use When
Build-time (NPM packages)	• Simple • Type-safe • Optimized	• Coordinated releases • No independent deploy	Shared component library
Runtime (Module Federation)	• Independent deploy • Version flexibility	• Runtime overhead • Complex debugging	Large orgs, independent teams
iFrame	• Complete isolation • Tech-agnostic	• Communication overhead • UX challenges (navigation, styling)	Legacy integration
Web Components	• Standards-based • Framework-agnostic	• Browser support • Limited state sharing	Shared widgets

Communication Patterns

Pattern	Use Case	Trade-off
Props	Parent to child	Simple but requires direct relationship
Custom Events	Cross-micro-frontend	Loose coupling but harder to debug
Shared State (Redux, Zustand)	Global coordination	Tight coupling
URL State	Deep linking, filters	Limited data types

Shared Dependencies

Problem: Each micro-frontend bundles React, lodash, etc., leading to duplication.

Solutions:

Module Federation (share at runtime)
External dependencies (load from CDN)
Monorepo (coordinate versions)

Trade-off: Sharing dependencies saves bandwidth but couples deployment.

Security Considerations

Authentication Patterns

Pattern	Pros	Cons	Use When
JWT in localStorage	• Simple • Accessible from JS	• Vulnerable to XSS • No automatic expiry	Simple apps with low risk
JWT in HttpOnly cookie	• Immune to XSS • Automatic send	• Requires CSRF protection • Complex CORS	Production apps (recommended)
Session cookie	• Server-side control • Easy revocation	• Server state • Scaling challenges	Traditional server-rendered apps
OAuth/OpenID Connect	• Delegated auth • Standard protocol	• Complex setup • Third-party dependency	SSO, social login

Data Validation

Layer	Purpose	Tools
Client-side	UX feedback	Zod, Yup, HTML5 validation
Server-side	Security (ALWAYS required)	Zod, Joi, class-validator
Type-level	Development safety	TypeScript, JSDoc

Golden Rule: Client validation for UX, server validation for security. Never trust client input.

XSS and CSRF Protection

XSS (Cross-Site Scripting):

Sanitize user input (DOMPurify)
Use React (auto-escapes by default)
Content Security Policy headers
Avoid dangerouslySetInnerHTML

CSRF (Cross-Site Request Forgery):

CSRF tokens
SameSite cookies
Double submit cookies
Origin header validation

Accessibility

WCAG Compliance

Level	Requirements	Use Case
A	Basic accessibility	Minimum legal requirement
AA	Reasonable accommodations	Standard target (most laws)
AAA	Highest accessibility	Specialized applications

Key Principles (POUR):

Perceivable: Alt text, captions, contrast
Operable: Keyboard navigation, focus management
Understandable: Clear language, consistent navigation
Robust: Semantic HTML, ARIA when needed

Performance vs Accessibility

Common Tension:

Heavy focus trapping (performance) vs. simple navigation (a11y)
Custom controls (design) vs. native controls (a11y)

Solution: Accessible patterns often improve performance:

Semantic HTML is lighter than div soup
Keyboard navigation reduces JS events
Screen reader support improves SEO

Testing Strategies

Tool	What it Catches	Limitations
axe-core / Lighthouse	30-40% of issues	Automated only
Keyboard testing	Focus management, operability	Manual
Screen reader testing (NVDA, JAWS, VoiceOver)	Real user experience	Time-consuming
jest-axe	Unit-level a11y	Limited context

Observability

Logging Strategies

Type	Use Case	Cost	Retention
Console logs	Development	Free	None
Application logs (Winston, Pino)	Errors, events	Low	7-30 days
Structured logs (JSON)	Queryable logs	Low	30-90 days
APM logs (Datadog, New Relic)	Production monitoring	High	90+ days

Best Practices:

Log levels (error, warn, info, debug)
Correlation IDs for request tracing
Avoid logging PII
Sample high-volume logs

Error Tracking

Service	Pros	Cons
Sentry	• Great DX • Source maps • Breadcrumbs	• Can be expensive at scale
Rollbar	• Good alerting • Telemetry	• Less intuitive UI
BugSnag	• Mobile-friendly • Session tracking	• Smaller ecosystem
LogRocket / FullStory	• Session replay • User context	• Privacy concerns • Expensive

Error Boundaries (React):

Prevent entire app crashes
Graceful degradation
User-friendly error messages

Performance Monitoring

Real User Monitoring (RUM):

Actual user experience
Geographic insights
Device/browser breakdown

Synthetic Monitoring:

Controlled tests
Consistent benchmarks
Early warning system

Key Metrics to Track:

Core Web Vitals (LCP, FID/INP, CLS)
Custom business metrics (time to checkout, etc.)
Error rates
API latency

Testing Strategy

Testing Pyramid

        /\
       /E2E\      Few (10%)
      /------\
     /  INT   \   Some (30%)
    /----------\
   /   UNIT     \ Many (60%)
  /--------------\

Level	Quantity	Speed	Confidence	Cost to Maintain
Unit	Many	Fast (ms)	Low	Low
Integration	Some	Medium (seconds)	Medium	Medium
E2E	Few	Slow (minutes)	High	High

Testing Types

Type	Tools	What to Test	What to Avoid
Unit Tests	Jest, Vitest	• Pure functions • Utilities • Hooks logic	• Implementation details • UI styling
Integration Tests	React Testing Library	• User interactions • Component integration • Data flow	• Mocking everything
E2E Tests	Playwright, Cypress	• Critical user paths • Multi-page flows • Real backend	• Testing every feature
Visual Regression	Chromatic, Percy	• UI consistency • Responsive design	• Dynamic content
Performance Tests	Lighthouse CI, WebPageTest	• Load times • Bundle sizes • Core Web Vitals	• Micro-optimizations

Test Coverage vs Speed

Trade-off:

High coverage (90%+) = slow CI, maintenance burden
Low coverage (30-50%) = faster, but less confidence

Balanced Approach:

70-80% unit test coverage
Test critical paths with integration/E2E
Avoid testing third-party libraries
Test behavior, not implementation

Anti-patterns:

Testing implementation details (how) vs behavior (what)
100% coverage dogma
Brittle selectors (test-ids preferred)

Deployment Strategies

Feature Flags

Benefit	Implementation	Trade-off
Progressive rollout	1% → 10% → 50% → 100%	Technical debt if not cleaned
A/B testing	Random user assignment	Complex analytics
Kill switch	Instant feature disable	Code complexity
Beta features	Opt-in for specific users	User segmentation logic

Popular Tools:

LaunchDarkly (enterprise)
Flagsmith (open source)
Unleash (self-hosted)
Custom Redis-based solution

Best Practices:

Clean up flags after full rollout
Use typed flags (TypeScript)
Default to safe fallback
Monitor flag performance impact

Progressive Rollouts

Strategy	Description	Risk Level	Use Case
Canary Release	Deploy to small % of servers first	Low	Backend changes, API updates
Blue-Green Deployment	Full environment switch	Medium	Major releases, database migrations
Rolling Deployment	Gradual server-by-server update	Low	Standard deploys
Shadow Mode	Run new version alongside old (no user impact)	Very Low	Testing in production

Monitoring During Rollouts:

Error rate spikes
Performance degradation
User complaints/support tickets
Business metrics (conversion, engagement)

Rollback Mechanisms

Mechanism	Speed	Complexity	Data Concerns
Feature flag toggle	Instant	Low	None (code still deployed)
Git revert + redeploy	5-15 min	Low	None (if stateless)
Blue-green switch	Instant	High	Database schema compatibility
Database rollback	Slow	Very High	Data loss risk

Golden Rule: Design for forward compatibility. Never break old clients.

Mobile Considerations

Responsive vs Adaptive

Approach	How It Works	Pros	Cons	Use Case
Responsive Design	Fluid grids, flexible images, CSS media queries	• One codebase • Future-proof • Easier maintenance	• Can be slow on mobile • Compromise on experience • Downloads unused assets	Most websites, content-heavy apps
Adaptive Design	Detect device, serve different layouts/bundles	• Optimized per device • Faster on mobile • Device-specific features	• Multiple codebases • More maintenance • Detection complexity	Apps with very different mobile UX
Hybrid (Responsive + Adaptive)	Responsive base + adaptive enhancements	• Best of both • Progressive enhancement	• Most complex	Large-scale applications

Decision Framework:

Same UX across devices?
├─ Yes → Responsive
└─ No → Consider Adaptive
    └─ Budget for maintenance?
        ├─ Yes → Adaptive
        └─ No → Responsive with mobile-first

Mobile-first vs Desktop-first

Approach	Philosophy	Pros	Cons
Mobile-first	Design for mobile, enhance for desktop	• Forces prioritization • Better mobile performance • Progressive enhancement • Smaller base bundle	• Desktop might feel basic • More CSS media queries
Desktop-first	Design for desktop, simplify for mobile	• Richer desktop experience • Familiar workflow	• Mobile as afterthought • Performance issues • Harder to simplify than enhance

Modern Best Practice: Mobile-first (60-70% of traffic is mobile for most consumer apps)

Mobile-specific Optimizations:

Optimization	Impact	Implementation
Touch-friendly targets	Better UX	Min 44x44px tap targets
Reduced animations	Battery, performance	`prefers-reduced-motion` media query
Image compression	Bandwidth savings	WebP/AVIF, responsive images
Offline support	PWA capability	Service Workers
Reduce font sizes	Performance	Font subsetting, system fonts
Lazy load below fold	Initial load time	Intersection Observer

Progressive Web Apps

PWA Capabilities:

Feature	Benefit	Browser Support	Implementation Effort
Add to Home Screen	App-like icon	Excellent	Low (manifest.json)
Offline Support	Works without internet	Good	Medium (Service Worker)
Push Notifications	Re-engagement	Good (not iOS Safari)	Medium (Push API)
Background Sync	Reliable data sync	Limited	High
Install Prompts	Increase installs	Variable	Low

PWA vs Native App Trade-offs:

Aspect	PWA	Native App	Winner
Development cost	Lower (one codebase)	Higher (iOS + Android)	PWA
Distribution	No app store	App stores	PWA (easier)
Device access	Limited	Full	Native
Performance	Good	Excellent	Native
Updates	Instant	Store review delay	PWA
Discoverability	SEO	App store optimization	Depends
Offline capability	Good	Excellent	Native

When to Choose PWA:

Content-focused apps
Limited budget
Need SEO
Frequent updates
Cross-platform priority

When to Choose Native:

Heavy device integration (camera, sensors, etc.)
Performance-critical (games, AR/VR)
Native UX is important
App store presence needed

Hybrid Approach (PWA + Native shell):

LinkedIn, Twitter use this
PWA for web, native wrapper for app stores
Shared web codebase

Interview Framework

How to Approach Questions

Step-by-step Framework:

1. Clarify Requirements (5 min)

Ask questions to understand:

Scale: How many users? Geographic distribution?
Features: Core vs nice-to-have?
Constraints: Timeline? Team size? Budget?
Users: Technical level? Devices? Network conditions?
Performance: What matters most? (SEO, TTI, offline, etc.)

Example Questions:

"How many concurrent users do we expect?"
"Is this a public-facing site or internal tool?"
"What's more important: initial load time or runtime performance?"
"Do we need to support offline functionality?"
"What browsers/devices must we support?"

2. Define High-level Architecture (10 min)

Structure your answer:

Rendering strategy (CSR/SSR/SSG)
State management approach
Data fetching pattern
Key infrastructure (CDN, caching)
Major trade-offs

Visual representation helps:

[User] → [CDN] → [Next.js SSR] → [API Gateway] → [Services]
                      ↓
                 [React Query Cache]
                      ↓
                 [Component Tree]

3. Dive into Components (15 min)

Pick 2-3 interesting areas to detail:

Performance bottlenecks
Complex state management
Real-time features
Security concerns

Show trade-off thinking: "I would start with X because [reason], but if we see Y problem, we could switch to Z."

4. Discuss Trade-offs (5 min)

For every decision, mention:

Why this choice? (requirements it satisfies)
What's the downside? (what we're sacrificing)
When would we change? (what would make us revisit)

5. Scaling & Evolution (5 min)

Discuss how the system evolves:

"At 10K users: Simple SSR works fine"
"At 100K users: Add CDN caching, API rate limiting"
"At 1M users: Consider ISR, edge functions, micro-frontends"

Common Pitfalls

Pitfall	Why It's Bad	Fix
Jumping to solutions	Miss requirements, wrong architecture	Always clarify first
Over-engineering	Adds complexity unnecessarily	Start simple, justify complexity
Ignoring trade-offs	Shows lack of depth	Every decision has pros AND cons
Buzzword dropping	Sounds hollow without context	Explain WHY you'd use a technology
Not asking questions	Seems overconfident or inexperienced	Show curiosity, clarify ambiguity
Ignoring non-functional requirements	Incomplete design	Consider security, a11y, i18n, monitoring
One-size-fits-all	Different problems need different solutions	Adapt to requirements
Forgetting about users	Too technical, not user-centric	Consider UX, accessibility, performance

Sample Answers

Example 1: Design Instagram Feed

Clarification Questions:

How many users? Daily active users?
Real-time updates required?
Image upload/processing requirements?
Offline support needed?

High-level Design:

Architecture:
├─ Rendering: SSR for initial feed (SEO, fast FCP)
├─ Client: React SPA after hydration
├─ State:
│  ├─ React Query for feed data
│  └─ Zustand for UI state (modals, selections)
├─ Real-time: WebSocket for new posts notification
└─ Media: CDN with progressive image loading

Key Decisions:

Rendering: SSR → CSR hybrid
- Why: Fast initial load + SEO, then rich client interactivity
- Trade-off: More complex than pure CSR
- When to change: If SEO isn't important, go CSR-only
Infinite Scroll with Virtualization
- Why: Smooth UX for long feeds
- Implementation: react-window + Intersection Observer
- Trade-off: Complexity vs. memory efficiency
Optimistic Updates
- Why: Instant feedback on likes/comments
- Trade-off: Need rollback logic if server fails
- Implementation: React Query mutations
Image Strategy
- Why: Images dominate bandwidth
- Approach:
  - Lazy load below fold
  - WebP with JPEG fallback
  - Responsive images (srcset)
  - Blur placeholder (LQIP)
Caching Strategy
- CDN: Cache images (long TTL)
- React Query: Cache feed data (5 min stale time)
- Service Worker: Offline image viewing

Scaling Considerations:

10K users: Single server SSR works
1M users:
- Edge SSR (Vercel, Cloudflare)
- Separate API gateway
- Image processing service
10M users:
- Feed sharding by user
- Read replicas
- Micro-frontends for features

Example 2: Design a Collaborative Document Editor (Google Docs-like)

Clarification:

Real-time collaboration required? (Yes)
Simultaneous editors expected? (Up to 50)
Mobile support? (Yes)
Offline editing? (Nice to have)

High-level Design:

Architecture:
├─ Rendering: CSR (no SEO need, auth-gated)
├─ Real-time: WebSocket with CRDT for conflict resolution
├─ State:
│  ├─ Local: Prosemirror/Quill editor state
│  └─ Sync: Yjs for distributed state
├─ Persistence:
│  ├─ Auto-save every 2s (debounced)
│  └─ Manual save option
└─ Offline: IndexedDB + sync on reconnect

Key Decisions:

CSR Only
- Why: Auth-gated, no SEO needed, heavy interactivity
- Trade-off: Slower initial load OK for tool
- Alternative: Could SSR shell for faster perceived load
CRDT for Conflict Resolution
- Why: Automatic merge of concurrent edits
- Options: Yjs (recommended), Automerge, operational transforms
- Trade-off: Complexity vs. robust collaboration
- Alternative: Last-write-wins (simpler but loses data)
WebSocket over Polling
- Why: Low latency, bidirectional
- Trade-off: Infrastructure complexity, connection management
- Fallback: Long polling for old browsers
Editor Choice: Prosemirror
- Why: Flexible, powerful, collaborative-ready
- Trade-off: Steeper learning curve vs. Draft.js/Quill
- Alternative: Quill (simpler, less flexible)
Optimistic Updates + Rollback
- Why: Instant typing feedback
- Implementation:
  - Apply change locally immediately
  - Send to server
  - Rollback if conflict/error
Cursor Positioning
- Show other users' cursors with names/colors
- Implementation: Relative positioning in CRDT
- Challenge: Performance with 50 users (throttle updates)

Performance Considerations:

Document Size:
- Paginate very long docs (100+ pages)
- Lazy load images/embeds
- Virtual scrolling for large docs
Collaboration Scale:
- Up to 10 users: Direct WebSocket
- 10-50 users: Throttle cursor updates (200ms)
- 50+ users: Consider room-based splitting
Memory Management:
- Cleanup old history (keep 100 operations)
- Garbage collect CRDT tombstones
- Unload off-screen content

Offline Strategy:

IndexedDB stores document + pending changes
Service Worker caches app shell
Sync queue when reconnecting
Conflict resolution UI if diverged

Example 3: Design an E-commerce Product Listing Page

Requirements:

10K products, need filters/search
SEO critical
Fast perceived performance
Mobile-first

High-level Design:

Architecture:
├─ Rendering: ISR (Next.js)
│  ├─ Static generation for popular products
│  └─ On-demand for long tail
├─ Search: Algolia/Elasticsearch
├─ Filters: URL state + React Query
└─ Images: CDN + progressive loading

Key Decisions:

ISR over SSR/SSG
- Why:
  - SEO (need server rendering)
  - Fresh inventory (revalidate every 5 min)
  - Scale (10K builds too slow for pure SSG)
- Trade-off: Next.js lock-in
- Alternative: SSR + aggressive CDN caching
Search: Algolia (managed) vs Elasticsearch (self-hosted)
- Algolia Pros:
  - Fast setup
  - Great DX
  - Built-in typo tolerance
- Algolia Cons:
  - Expensive at scale
  - Vendor lock-in
- When to switch: Over 1M searches/month → consider Elasticsearch
Filter State in URL
- Why: Shareable links, back button works
- Implementation: URLSearchParams + React Router
- Trade-off: URL can get ugly with many filters
Virtualization for Long Lists
- Why: 1000+ products per page possible
- Implementation: react-window
- Alternative: Pagination (simpler, SEO-friendly)
- Decision: Use pagination with "Load More" for SEO
Image Strategy
- Blur placeholder (LQIP)
- Lazy load (Intersection Observer)
- Responsive images
- WebP with JPEG fallback
- CDN with automatic optimization (Cloudinary)

Performance Budget:

LCP < 2.5s (hero image)
FID < 100ms
CLS < 0.1 (reserve image space)

Caching Strategy:

ISR: Revalidate every 5 min
CDN: Cache static assets 1 year
Browser: Cache product images 1 week
API: React Query cache 5 min, stale-while-revalidate

Mobile Optimizations:

Sticky filters button (mobile)
Bottom sheet for filters (not sidebar)
Touch-friendly product cards (min 44px)
Reduce image quality on slow connections

Key Takeaways

Universal Principles

No Silver Bullets: Every decision trades one benefit for another.
Start Simple: Complexity should be justified by requirements, not resume building.
Measure First: Don't optimize what you can't measure.
User-Centric: Performance metrics exist to serve user experience.
Evolutionary Architecture: Design for change, not perfection.

Interview Success Formula

Great Answer = Clear Communication
             + Trade-off Awareness
             + Justification
             + Adaptability

Remember:

Interviewers want to see your thinking process, not just the answer
There's rarely one "correct" solution
Asking clarifying questions shows experience
Acknowledging limitations shows maturity
Discussing when you'd change approaches shows depth

Red Flags to Avoid

❌ "We should use microservices/GraphQL/etc." (without justification) ❌ "This is the best way to do it" (no trade-off awareness) ❌ Over-engineering for small scale ❌ Ignoring non-functional requirements (security, a11y) ❌ Not considering costs (infrastructure, maintenance, developer time)

Green Flags to Show

✅ Ask clarifying questions first ✅ Start with simple solution, then iterate ✅ Mention trade-offs for every decision ✅ Consider different scales (10K vs 1M vs 10M users) ✅ Think about maintenance and team velocity ✅ Consider total cost of ownership ✅ Show awareness of modern best practices ✅ Be honest about what you don't know

Quick Reference Cards

When to Use What

Rendering:

CSR: Dashboards, auth-gated tools
SSR: E-commerce, social media, content
SSG: Blogs, docs, marketing
ISR: Product catalogs, news sites

State Management:

Local: UI toggles, forms
Context: Theme, i18n, auth status
React Query/SWR: Server data
Redux/Zustand: Complex business logic

Data Fetching:

REST: Default choice, simple CRUD
GraphQL: Complex nested data, mobile apps
tRPC: Full-stack TypeScript monorepos

Styling:

Tailwind: Fast development, consistency
CSS Modules: Component libraries
CSS-in-JS: Heavy theming needs
Plain CSS: Simple sites, performance-critical

Performance Quick Wins

Images: WebP, lazy load, responsive srcset
Fonts: System fonts or subset web fonts
Code Splitting: Route-based, dynamic imports
Compression: Enable Gzip/Brotli
Caching: HTTP headers, CDN, React Query
Bundle: Tree shaking, minification
Critical CSS: Inline above-fold styles
Preload: Critical resources

Common Interview Questions

"Design a news feed (Twitter/Instagram/Facebook)"
"Design a real-time collaborative editor (Google Docs)"
"Design a video streaming platform (YouTube)"
"Design an e-commerce site (Amazon)"
"Design a chat application (WhatsApp/Slack)"
"Design a file storage system (Dropbox)"
"Design a dashboard with real-time data"
"Design a booking system (Airbnb)"

For each, remember to discuss:

Rendering strategy
State management
Real-time needs (if any)
Caching strategy
Performance considerations
Scaling approach

Additional Resources

Practice Platforms

Frontend Mentor (UI challenges)
GreatFrontEnd (system design questions)
LeetCode (algorithmic problems)
Pramp/Interviewing.io (mock interviews)

Final Note: This guide is a reference, not a script. Use it to develop intuition about trade-offs, then adapt to each unique situation. The best engineers don't memorize solutions—they understand principles and apply them contextually.

Good luck with your interviews! 🚀

Table of Contents​

Introduction​

Rendering Strategies​

CSR vs SSR vs SSG vs ISR​

Hydration Strategies​

Streaming SSR​

State Management​

Local vs Global State​

Server State Management​

State Synchronization​

Data Fetching​

API Architectural Patterns​

Caching Strategies​

Real-time Data​

Performance Optimization​

Bundle Optimization​

Runtime Performance​

Network Performance​

Rendering Performance​

Component Architecture​

Component Patterns​

Composition vs Inheritance​

Code Reusability​

Styling Approaches​

CSS Methodologies​

Runtime vs Build-time​

Theming Systems​

Routing Architecture​

Client vs Server Routing​

Route-based Code Splitting​

Deep Linking​

Micro-Frontend Architecture​

Integration Approaches​

Communication Patterns​

Shared Dependencies​

Security Considerations​

Authentication Patterns​

Data Validation​

XSS and CSRF Protection​

Accessibility​

WCAG Compliance​

Performance vs Accessibility​

Testing Strategies​

Observability​

Logging Strategies​

Error Tracking​

Performance Monitoring​

Testing Strategy​

Testing Pyramid​

Testing Types​

Test Coverage vs Speed​

Deployment Strategies​

Feature Flags​

Progressive Rollouts​

Rollback Mechanisms​

Mobile Considerations​

Responsive vs Adaptive​

Mobile-first vs Desktop-first​

Progressive Web Apps​

Interview Framework​

How to Approach Questions​

1. Clarify Requirements (5 min)​

2. Define High-level Architecture (10 min)​

3. Dive into Components (15 min)​

4. Discuss Trade-offs (5 min)​

5. Scaling & Evolution (5 min)​

Common Pitfalls​

Sample Answers​

Example 1: Design Instagram Feed​

Example 2: Design a Collaborative Document Editor (Google Docs-like)​

Example 3: Design an E-commerce Product Listing Page​

Key Takeaways​

Universal Principles​

Interview Success Formula​

Red Flags to Avoid​

Green Flags to Show​

Quick Reference Cards​

When to Use What​

Performance Quick Wins​

Common Interview Questions​

Table of Contents

Introduction

Rendering Strategies

CSR vs SSR vs SSG vs ISR

Hydration Strategies

Streaming SSR

State Management

Local vs Global State

Server State Management

State Synchronization

Data Fetching

API Architectural Patterns

Caching Strategies

Real-time Data

Performance Optimization

Bundle Optimization

Runtime Performance

Network Performance

Rendering Performance

Component Architecture

Component Patterns

Composition vs Inheritance

Code Reusability

Styling Approaches

CSS Methodologies

Runtime vs Build-time

Theming Systems

Routing Architecture

Client vs Server Routing

Route-based Code Splitting

Deep Linking

Micro-Frontend Architecture

Integration Approaches

Communication Patterns

Shared Dependencies

Security Considerations

Authentication Patterns

Data Validation

XSS and CSRF Protection

Accessibility

WCAG Compliance

Performance vs Accessibility

Testing Strategies

Observability

Logging Strategies

Error Tracking

Performance Monitoring

Testing Strategy

Testing Pyramid

Testing Types

Test Coverage vs Speed

Deployment Strategies

Feature Flags

Progressive Rollouts

Rollback Mechanisms

Mobile Considerations

Responsive vs Adaptive

Mobile-first vs Desktop-first

Progressive Web Apps

Interview Framework

How to Approach Questions

1. Clarify Requirements (5 min)

2. Define High-level Architecture (10 min)

3. Dive into Components (15 min)

4. Discuss Trade-offs (5 min)

5. Scaling & Evolution (5 min)

Common Pitfalls

Sample Answers

Example 1: Design Instagram Feed

Example 2: Design a Collaborative Document Editor (Google Docs-like)

Example 3: Design an E-commerce Product Listing Page

Key Takeaways

Universal Principles

Interview Success Formula

Red Flags to Avoid

Green Flags to Show

Quick Reference Cards

When to Use What

Performance Quick Wins

Common Interview Questions